home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 761 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.7 KB
  1. Date: Wed, 13 Jul 94 08:58 BST-1
  2. From: Ofir Gal <ogal@cix.compulink.co.uk>
  3. Subject: Re: Buttons Buttons Buttons
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.636554@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9.  
  10. In message <m0qNwNU-0000oTC@sdf.lonestar.org>, ekl@sdf.lonestar.org said:
  11.  
  12. >Tool-based Applications : All other buttons are used to select tools.  So,
  13.  
  14. This is exactly as implemented in DA's Picture and is very useful although
  15. it takes a while to get used to.
  16.  
  17. >Other Applications : The secondary mouse button is to be used to pop-up a
  18.  
  19. It was already mentioned that this is not the standard behaviour for the
  20. right (2nd) button. There are basically three approaches in use:
  21.  
  22. 1. Ignore right button - not very useful
  23.  
  24. 2. Holding the right button allows clicking in background windows with the
  25.    left button, very useful and also the standard behaviour. Works very
  26.    well in the desktop and Papyrus is another example where you can move
  27.    the cursor around and even select text while in the font selector.
  28.  
  29. 3. Allow the right button to be used on background windows without topping
  30.    them. I personally find this very useful and implemented it in my
  31.    toolkit as a user option. It is also used in Datalite and Ease where
  32.    you can move/copy/drag files without having to top windows.
  33.  
  34. 4. As you suggest when using the Tools idea as in DA's Picture.
  35.  
  36. >In any case, if you wish to implement a permanent menu that stays on
  37.  
  38. This is already imlemented very nicely in Geneva. It is indeed a very
  39. useful feature. You can grab any menu by clicking its Title while holding
  40. CTRL. I think that this is a nice method although it does not work for
  41. popups or sub-menus. The application will have to provide this feature for
  42. popups and window menus.
  43.  
  44. >until closed.   Also, this should only be done for right-button menus.
  45. >Menus called from a 3rd or 4th button (even if called from a background
  46. >window) should never stay in a window, and pop-up info should only stay
  47. >until you release the mouse button) although these menus should be
  48.  
  49. Why? What does the right mouse have to do with all this. First, all this
  50. will only be useful for some and not all apps and secondly, methods 2 and
  51. 3 are much more standard and useful.
  52.  
  53. >Oh .. I forgot to mention this.   NEVER force the user to hold both
  54. >buttons to produce any effect.  The only reason to hold two buttons is
  55.  
  56. See 2.
  57.  
  58. >they will explain.  Do NOT hack things by using the right button to
  59. >modify the event you get with the left button.  You CAN get separate
  60.  
  61. With this I agree, except as mentioned in 2 and possibly 3.
  62.  
  63. Bye,
  64.  
  65. -----------------------------------------------------------------
  66. Ofir                                    ogal@cix.compulink.co.uk
  67. -----------------------------------------------------------------
  68.  
  69.